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PRESIDENT’S CORNER 
de WA7GXD 
Tucson Amateur Packet Radio is turning a corner. 


Three years ago there was only one source of 
Amateur packet equipment. and it was oriented for 
the dedicated experimenters in our ranks. TAPR's 
Beta test of 1983 proved that packet had appeal to 
the mainstream of Amateur radio operators. The 
demand for Beta boards led to the TNC 1 kit later 
that same year. 


Within afew months, AEA and later Heath began 
marketing clones of the TNC 1. GLB began selling 
their innovative PK-: TNC. Soon. Kantronics, 
Packeterm and others were partcipating in the 
Amateur market. Recognizing the need for a low- 
cost, highly functional TNC, TAPR introduced the 
TNC 2 in mid-1985. 

And then we changed our course. Turned the corner 
I mentioned above. 


Until this year, most of TAPR's income was through 
sales of TNC kits. Membership dues played a very 
minor role in financing the services and 
development efforts that many of you have come to 
expect from us. 


Now, we are undertaxing two large and difficult 
tasks. The Network Node Controller, or NNC. 
project is completing digital hardware development 
and is heading out to the software coders. And a 
higher-speed moden/rf deck project is being 
actively pursued. Time, energy and money will be 
absorbed by these projects in increasing amounts 
as the year wears on. 


But our nain source of 
curtailed. 


revenue, TNC sales, is 


We are attacking the financial constraints in two 
Ways. 


The first, is by more carefully using the money we 
have. Several cost-cutting measures have been put 
in place. 


The office is now open only four days a week. 
Tuesday through Friday. This saves us a few 
thousand dollars on an annual basis. 


Continued on next page. 


TAPR GOALS - 1986 


What's a TAPR? What does TAPR do? 
exist? Why should I join? 


Why does TAPR 


At its February Board meeting, the following three 
goals were set for Tucson Amateur Packet Radio. 


1) Tucson Amateur Packet Radio will take an 
active role in participating in the FCC 
rule making process on issues relating to 
Amateur packet radio. Further, TAPR will 
coordinate such activities with other Amateur 
organizations. 


2) Tucson Amateur Packet Radio will seek better 
and faster ways of providing information to 
the Amateur packet community. 


3) Tucson Amateur Packet Radio will encourage 
and support hardware and software projects to 
advance the state of the art in Amateur pac- 
ket communications. 


How are we doing tn these areas of activity? 


The Board established a committee for regulatory 
matters, and that committee responded very rapidly 
to a very urgent matter. 


The FCC Report and Order on Docket 85-105 
have enforced a very strict, 
what oudated, definition of third party traffic. 
The intent of the Docket was to support packet 
operation, legitimizing many operating practices 
by allowing automatic unattended digital operation 
above 50 MHz. The third party clause, however, 
would have been very detrimental to Amateur packet 
radio development. 


would 
and we believe sone 


TAPR filed a fairly lengthy Petition for Reconsid- 
eration, along with other concerned Amateurs and 
Amateur organizations. 


Happily. the FCC has responded to these Petitions, 


as wel! as a Petition for Extraordinary Relief 
filed by the ARRL. and we are now allowed to 
operate digipeaters and PBBSes with third party 


traffic while the FCC digests the comments of the 
petitioners. 


See elsewhere in this PSRQ for the text of 
filing and the FCC's amended rules. 


TAPR's 


Continued on page 4, 


President's Corner Continued 

We are reducing the number of people we send to 
conventions. For example, this year TAPR IS only 
sending three “official” representitives to 
Dayton, although we will have a booth there. 


We are applying for a second-class postage permit 
to reduce the cost of mailing your PSR Quarterly, 
while still providing nearly first-class handling 
and service by the Postal Service. Foreign 
subscriptions will continue to be sent Alr Mail, 
however. . 


(Speaking of PSRQ, this issue is being printed and 
mailed by the gang at Colorado Springs, headed up 
by Andy Freeborn, NOCCZ. This helps relieve some 
of the pressure in Tucson, and I certainly want to 
thank Andy for the assistance!) 


In the past, 
inpronptu arrangement, 
type. Now, 


projects were “hatched” by an 
without budgeting of any 
the Board has established a Projects 
Committee. This allows anyone to submit a project 
proposal] to TAPR for review. It also establishes 
controls, and involves the Board directly in the 
approval cycle. 


Elsewhere in the PSR you will find an article 
providing guidelines for submitting a project 
proposal to TAPR. 


And, if you read the minutes, you will note that 
the Board is inviting non- Board members of TAPR to 
participate in Project definition, approval and 
execution. 


one very positive aspect of all this is the chance 
for greater and more meaningful participation in 
the advances in packet radio by the general 
membership of TAPR. In other words, you! 


The other side of the financial health of the 
organization relates to incone. It is fine to 
control expenses, but only if you have something 
to spend! 


The first and perhaps largest step taken was in 
the restructuring of the ORM licensing egreement 
for TNC 2. 


You may recall that TNC 1 licenses cost only $500 
on a one-time basis. 


The TNC 2 license costs $5,000 plus royalties 
stretching over two years. Thus, while we are not 
actively in the TNC marketplace, our income is 
still closely tied to the marketplace. 


If you or a friend 1s on the fence about which TNC 
to buy, you might consider that every TNC 2 
licensed product sold provides a small amount to 
TAPR for continued development of networking and 
other resources that will help transform packet 
from a mode of high potential to a mode of great 
achievement. 


Finally, I ask that you look at your address 
label. If your membership is about to expire, 
please renew quickly. We have never had a dues 
increase since our inception in 1981. Packet 
radio wouldn't be where it is today without your 
support. And please encourage others to join and 
help support the Packet Revolution! 


ELIMINATING POOP FROM PACKET 


Peter Eaton. WBOFLW, and Lyle Johnson. WA7GXD 


(Note: this material is being printed in PSRQ by 
popular demand. It may be considered offensive 
by sone, to whom we apologize in advance. The 


message it contains, however, is very timely. Ed.) 
Overview 


A lot of poop has been discovered on packet 
frequencies across the nation and around the 
world! Indeed, in addition to fits health and 
welfare implications, POOP is both unnecessary and 
oftentimes offensive. 


While other four-letter acronyms have been used to 
describe the characteristics of POOP, it is hoped 
that POOP is sufficiently recognizable by packe- 
teers to eliminate the need to express the others! 


What, exactly, is POOP? How does one elininate 
1t? How can one help others to cause it to not be 
propogated? The answers to these questions form 
the basis of this paper. 


POOP - What is it? 


POOP is simply an acronym for Poor Operating On 
Packet. While it may evoke other thoughts in 
one's mind, the relationship between those other 
thoughts and poor operating practices is probably 
pretty clear and will not be further elaborated 
upon. 


POOP - How does one eliminate it? 


In order to eliminate POOP, one must simply not 
generate it. If it is generated, it will be 
passed onto packet channels, needlessly clogging 
thea. 


While there are many varieties of POOP, and it 
would be impossible to describe them all in this 
paper. several of the more obnoxious and prevalent 
forms of it are described. 


Frog POOP 


If you have ever been around a pond, you have 
undoubtedly heard the loud and constant noise put 
on dy frogs. It seems amazing that so small a 
creature can make such a disturbance! 


If you have ever monitored a busy packet channe}, 
you have probably seen plenty of beacon messages. 
Here again, a large disturbance may be caused, 


Beacon features were included in TNC software in 
the early days of packet when stations were few 
and far between. Like the frog on the pond, the 
noises were made to attract attention of like 
species -- in this case, other packet stations. 
Unlike the frog. who settles down after he gets 
what he was looking for, many packeteers continue 
to send beacons, often on crowded channels. 


Some packeteers contrive clever beacons, to sound 
bells. clear screens. or print multi-line declara- 
tions on the screens of all who can decode the 
beacon. 
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The proper rules governing beacons are simple: 
1) Determine why you need to beacon. 


Beacons declaring that you are unavailable, or on 
vacation. are perfectly useless and mark you as a 
real POOPer. If the information you are attemp- 
ting to convey 1s isportant, perhaps leaving it as 
@ message addressed to all on the nearest packet 
bulletin board station (PBBS) is a better alterna- 
tive. 


On the other hand. if you are living in tornado 
alley and see a funnel, an urgent beacon may be 
appropriate. 


(In-search-of POOP) 


If the purpose of your beacon is to let folks know 
you are around and want to connect, it may de 
better to just turn on the radio and let your TNC 
decode a few packets from other stations. This 
way you can see who is on and then simply send a 
connect request rather than a beacon. 


Many new TNC software releases include an MHEARD 
function, allowing you to see the contents of a 
buffer containing the last several packet stations 
heard by your station. 


If you are convinced that you must transmit with- 
out listening for a few alnutes (or if the channel 


really does appear dead), dropping into UNPROTO 
mode (CONVERSE mode from COMMAND mode without 
first connecting) and typing a short CQ message 
(which may be as sinple as a carriage return if 
UNPROTO is set to CQ) is preferable to beaconing 
one 


2 Compose the briefest possible beacon text. 


Cute beacons that fill a sereen, sound bells. or 
clear screens will only mark your statioh as obno- 
Xious. Ie is a classic way to lose friends and 
increase your count of enemies! 

3) Use the BEACON AFTER mode rather than BEACOK 
EVERY. 


If the channel is busy. one-way broadcasts (which 
ls, after all. what a beacon really 1s] are not 
welcome. It's bad enough to try and maintain a 
connection through a digipeater or two without 
having having a channe! clogged by transmissions 
from unattended stations that come on the air 
every few minutes. Beacon AFTER with a value of 
thirty minutes will assure that you do not add to 
busy channel bedlan. 


4) Don't send beacons amore often than every 
thirty minutes, preferably less frequently. 
(TNC 1 and TNC 2 users. B A 180 is the recon- 
mended setting.) 


5 Digipeat beacons with care! 


Digipeating may cause a large number of 
packeteers to be subjected to screens full of your 
beacon text. This may be desirezble. Then again. 
it may not. Consider your motive and objective 
for your particular beacon. then set up the path. 


Squid POOP 


As Amateurs, we admit to occasional spelling er- 
rors. We meant Scwid (Sending CWID)... 


loca! 


Sending a CWID is somewhat akin to using class 8B 
(spark} transmissions on the lower end of 20 
meters when the band is open. It's annoying and 
serves no useful function. 


The CWID feature was included in earlier TNCs to 
help the uninitiated masses of Amateurs identify a 
station that was making “packet racket.” The 


decoder of the CW would (hopefully) contact the 
station sending the CWID and inform him of the 
strange noises eminating from his radio. upon 
which the proud packeteer would politely inform 


the bearer of the bad tidings that the noise was 
intentional. In the ensuing conversation and 
demonstration, another convert would then be won 
over to the new way of communicating. 


Besides, the 
minutes or so! 


FCC once required a CWID every ten 


Nowadays, the FCC has recognized our heretical 
behavior, packet is state-sponsored and CWID is no 
longer required of packet stations. 


As a final note, most packet operation occurs on 
VHF. and everybody knows that most folks on VHF 
can't copy code anyway! 


Bull POOP 


Try entering a field containing a bull. While 
many bulls are mild mannered, some are very terri- 
torial and will chase you away. 


The same is true of a packet BULLetin board sta- 
tion. Many are mild mannered, aware of other pac- 
ket stations on the channel and content to share 
the channel with then. 


Others, however. are not. They will chase you 
away unless you came to feed thea. 


They do it quite simply, and often are ignorant of 
their ferocity. 


A skilled matador, however. can soon tame a fero- 
cious bull. So can the operator of a PBBS dane 
his BULL. 


The keys are TNC setup files. Most PBBS software 
contains a flle (or files) describing the charac- 
teristics of the TNC(s) attached to the computer 
serial port(s). The magic commands are PACLEN, 
MAXFRAME and DWAIT. 


If a PBBS is operating on HF, PACLEN should be 
fairly short, perhaps 40 or so. Since this para- 
meter describes the length of the information 
field, not the header and contro] bytes, a setting 
in excess of 80 (the length of one line on most 
computer displays} is probably the longest needed. 


MAXFRAME can be 
bandwidth reduction. 


the cause of a lot of useful 
If the PBBS is on a channel 


shared by other users, MAXFRAME 1 its reasonable. 
We have heard PSBS‘'s sending packets of many 
frames to stations that were having a hard tire 


decoding anything, and the channe! was reduced to 
uselessness ‘or other stations. Similarly, we 
have often heard PBBS's on HF sending long packets 
of multiple long frames. getting an ACK on the 
first one only (if any). and repeating the process 
over and over. Computers are infinitely patient, 
but humans wanting to use the channel may not be! 
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DWAIT is perhaps the strongest medicine to 
to an overly possessive SULL. pBBS 
should set DWAIT to 320 milliseconds. For a TAPR 
TNC 1 running 3.X software, this corresponds to 
OWAIT 8; for a TNC 2 it is DWAIT 32. 


apply 
stations 


It vou are not the owner of a BULL, but 
into territory where one lives, 
the beast! 

recommended: 


venture 
you can help tame 
The following suggestions are highly 


1) DO NOT DX A PBBS! In this case, DX 
multi-hop digipeating to a PBBS on VHF. 


means 


2) Don't send the PBBS a command before it has 
responded to your previous command! 


Hitting a key twice (or hitting it harder!) WILL 
NOT improve your chances of getting through! The 
nature of a packet system is that the message gets 
through accurately, or not at all. Sometimes it 
may take a while, especially if a digipeater or HF 
Link Is involved, but it will get through. If 
not, you will get a 

*** DISCONNECTED message. 


Untimely POOP 

POOP can't easily be made timely, but Tücs can! 
And TNC's that aren't timely can sure contribute 
to the level of POOP on a packet channel! 


In the January, 
Clark, WSIWI, 


1986 issue of PSR Quarterly, Tom 
made a convincing argument for the 


setting of the ODWAIT parameter for all packet 
operations. His recommendations are: 
Tine TNC 1 TNC 2 
User type mSec DWAIT DWAIT 
Digipeaters 0 0 0 
keyboard users 160 4 16 
PBBS, Hosts 320 8 32 
File Transfer 480 12 48 
Digipeaters wind up with the highest priority. 


Since these stations are the moat susceptible to 
collisions, and generate the most congestion on a 
retry. they deserve first shot at an empty time 
slot. 

Keyboard users. operating in a keyboard-to-key- 
board QSO, generate little traffic. After all, 
one can only type so fast! They get the next 
priority. 


PBBS and host stations generally produce a fair 
amount of data out for a little data in. Thus, 
the keyboarder has priority getting into the PBBS, 
but the PBBS waits for other keyboard users before 
dumping what will probably be a longer packet onto 
the channel. 


Pile transfers, generating the most data and hence 
requiring the most bandwidth, are requested to be 
more polite and give other users a fair shot at 
the shared channel. Thus, they are held off the 
longest. 


Wide adoption of this scheme may not significantly 
reduce congestion on a channel, but it should help 
the channel operate on a fairer basis than other- 
wise. 


Snake POOP 


A anake has a fairly unique characteristic, A 


snake has no ears! 


Too many packeteers seem to have the impression 
that, by connecting a TNC to the speaker jack on 


their radio, they don't have to have a speaker 
connected! 

The results can often de observed. Excessive 
retries on a channel because the antenna isn't 


oriented properly, leading to multipath and poor 
reception. The other end of the link simply “goes 
away” for no apparent reason (unless you are lis- 


tening!). The other station is over-deviating. or 
another user on another mode, or... And, on a 
shared-mode channel (or shared repeater). packet 


can get a bad name in a burry! 
Kangaroo POOP 
files 


A kangaroo jumps around. If you have long 
to transfer. you should jump around, too! 


A busy channel during the early evening hours is 
not the place for file transfers, automatic nes- 
sage forwarding or similar bandwidth-hungry proce- 
dures. What can you do? Jump off to another 
frequency. perhaps. If this is not feasible, set 
your alarm for 3 AM and jump to another tlne, 
eating up the channel then. 


POOP - the final scoop 


The ultimate means to eliminate POOP is to SCOOP! 
By means of the SCOOP, no one wil! ever be able to 
detect packet POOP emanating from your station? 


SCOOP means Setting correct Operating Parameters. 
If you heed the advice to avoid POOP given above, 
this final measure will permit you to have a full 
clean-air rating! 


Happy packet Ing! 


—— . 


TAPR Goals - 1986 Continued from page 1 


Expect other positive action from this comnittee. 
And remember, they need your input! Write to the 
TAPR office, and mark the envelope ATTN: 
REGULATORY COMMITTEE. 


Item 2, finding faster and better ways to connuni- 


cate with the Amateur packet committee, led to 
another committee! This one is looking into, 
among other things. locating an economical elec- 
tronic messaging service that can be accessed 
easlly. 

DRNET is one possibility. It has proved Invalu- 


able for coordination among the TAPR Board and 
Officers. The TNC 2 would not have happened with- 
out ORNET. And. while “free” accounts are 111 
ted, subscription accounts seem to be available. 


The GENIE network, sponsored by General Electric, 
is also being investigated. Hopefully, the next 
PSRQ will contain details on the selected option. 


Packet development issues, addressed by point 
three. led to the creation of the projects conmit- 
tee. Elsewhere in this PSRQ is an article con- 
taining guidelines for project submission. 


Meanwhile, the NNC and high-speed 
projects are underway. An HF tuning indicator 
semi-kit should be available at Dayton. based on 
the article by Dan Vester in the Ocotber PSRQ. 


radio/moden 


Got an idea? Let us know! 


— re ean ae ee 
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BBS NEWS N VIEWS 


Tom Clark, W3IWI 
IBM-PC BBS 


Well. a lot has happened since our last report. 
Let's start out on the IBM-PC front. Jeff 
Jacobsen, WATMBL released his version 2.04 "RLI 
clone” BBS and it has gotten rave reviews. Here at 
W3IWI I retired the old Xerox 820 BBS system in 
early March after a year and a half of faithful 
service, replacing it with an I[BM-PC clone. The 
configuration in use here is a Mitsubishi/Leading 
Edge "Model M“ with 640 kbytes of RAM, a 20 Meg 
“prand x“ hard disk, IBM's PC-DOS 3.1 and two 
TNC2's. I am amazed at how reliable this systen 
has been; with the exception of a problem related 
to DoubleDOS (more on this later), the system 
hasn't given any trouble at all; it's so reliable 
that it 1s boring! g 


There are several features in the HBL software 
have made my life a lot easier. In the original 
WORLI version, Hank kept all the “alive” mail in 
one long disk file. This file was structured as a 
disk-based linked list with the pointer threads“ 
embedded in the same file. When the mail file grew 
to sore than about 50 messages, and when there had 
been a lot of sessage deletions, this linked-list 
became very tangled and disk access times slowed 
waaaaayyyyyYyYYYyy down. flank provided the 
UNTANGLE.COM utility in the early versions, and 
incorporated this function into the 6“ consand tn 
later versions. SYSOPs at busy systems like W3IWI, 
A120. WORLI, etc. found It necessary to 67 once 
or twice per day. The linked list was rather 
vulnerable to isolated bad disk sectors. I dare 
say there is probably not a single WORLI systen 
that hasn't had the MAIL.DAT file crashed at least 
once! 


In the WA7MBL code, the text of each message is 
maintained as a separate file. Two supporting 
files contain the message headers and message 
indexing information. These files are updated 
continuously and there is no “untangle” necessary. 
I figure that this alone has saved me 15-30 min- 
utes each day since I made the change to the PC. 


The other nice new feature is that Jeff has writ- 
ten his code so that it can be started fron the 
DOS AUTOEXEC.BAT file. If you have a hardware 
clock in your PC which sets the software clock, 
then you can be immune from the effects of power 
failures. In fact, ay instructions to my wife in 
case the system has to be reset when I'm away ona 
trip are “turn the power off. then on again”. 


The typical user notices little difference between 
the 'RLI and 'MBL software when it comes to mes- 
sages posted on the BBS. The big change concerns 
the accessing of files. Jeff's code supports the 
use of multiple directories which can have des- 
criptive nanes rather than the cryptic B:“ of 
CP/M. If the user merely types u he sees the 
names of all the available directories plus any 
files that are in the “root” directory. Here at 
W3IWI. the only “root” file is called FILEINFO 
which tells about what is in all the other direc- 
tories. This architecture, coupled with the large 
volume of storage afforded by a hard disk gives 
the users access to a lot of information (probably 
more than he can ever hope to digest!). 


I have seen a number of other BBS systems change 
over from Xerox 820's to IBM-PC clones in the past 
couple of months and I am continually deluged with 
requests for disks. A couple of comments on soft- 
ware distribution seem in order. Jeff has asked 
Wes Morris, K7PYK to serve as his "official" dis- 
tribution channel]. Several others have tried to 
help out too; software seens to spread thru the 
cosnunity like a growth of mold. Jeff has asked 
repeatedly that he not be deluged with requests. 
He can either answer the requests, or work on new 
code, but not both at the same time. We are al} 
much better off if he Is al loved to be creative! 


Jeff's code for the PC has only been around for a 
few months and yet it has already made a remark- 
able impact on packet radio. Jeff has shown that 
an isolated individual can make a significant 
contribution from the “backwoods” of Ogden Utah. I 
hope this serves as a model of what YOU can do for 
your hobby! 


XEROX 820 


It may be surprising, but it is only two years 
since Hank Oredson, WORLI set out to nake his 
contribution. Hank's efforts on the 6820's got 
packet radio moving. It gave us our first real 
“network”. With the release of WORLI version 11.2 
in early February, Hank made the decision to nove 
on to newer, more challenging tasks. I know I 
speak for all the packeteers in telling Hank 
“Thanks for a job wel) done!“. 


Hank threw the gauntlet down on the table and 
challenged someone else to pick it up. Well, a new 
knight has emerged in Ed Picchetti, K3RLI (we 
can't seem to get RLI out of this!). Ed has now 
made available his version 11.4 which adds a 
couple of enhancements to the (other) 'RLI's 11.2. 
One of the enhancements was already available in 
the ‘MBL code: the ability to specify a maxinun 
number of digipeaters for local users which can be 
over-ridden by other BBS's for mail forwarding. Ed 
also added another neat feature (not yet supported 
by 'MBL) which allows a bulletin to be forwarded 
to a number of other BBS systems in one operation. 


When I saw Ed last week, he made a plea: “Don’t 
consider the 820's as being dead. They still have 
a lot of life left in them.” I have to agree with 
Ed; even though I "retired" my 820 from the main 
BBS, I still have {t in active use as a 
221.01/1465.05 Gateway. 


FCC 85-205 


Another big event has been all the activity assoc- 
fated with the FCC's Report and Order 85-105. This 
came in response to the earlier RM-4879 Notice of 
Proposed Rule Making (NPRM). As it came out fros 
the FCC, 85-105 was an unmitigated disaster! All 
of us who read the document were appalled at bow 
little the Commission knew about what we were 
already doing. Had 85-105 taken force, the effect 
would have been to shut down virtually all packet 
radio BBS and networking activities. The problem 
lay in the definition of third-party traffic and 
the FCC's apparent paranoia that unlicensed hack- 
ers and commercial users would gain uncontrolled 
access to packet radio resources. 


After 85-105 hit the street. TAPR, the ARRL and a 
number of individuais submitted strongly worded 
Petitions for Reconsideration. The ARRL worked 
very hard and succeeded in obtaining temporary 
relief while the matter is reconsidered. 
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Although we are temporarily “saved” let us not 
rest On our laurels. This matter wil] be coming up 
again. When the original NPRM was in front of us 
for comments, less than two dozen individuals and 
organizations took the time to submit our con- 
ments. Our own complacency almost did us in. The 
TAPRites who have been charged with lobbying to 
try to improve our image in these matters are 
NK GSK. WA7GXD, W3VS and W3IWI. Please let us know 
your thoughts. And this time, when we flash the 
bulletins that it is time to write the FCC again, 
DO IT! Don't assume that someone else will carry 
the ball. . 


Unrelated to 65-108, but hitting at the same tine, 
is the FCC's overt decision to clamp down on HF 
BBS/Gateway/linking. The bombshell hit in late 
January when K4TKU was cited by the FCC monitoring 
station in Maine for unattended operation of an 
automatic BBS. Since then, HF activity has taken a 
noticeable nosedive. The HF BBS SYSOPs are more 
circumspect about leaving their systems on during 
the daytime when they are away at work. This has 
led to a greater emphasis on evening HF activity. 
and with 20 meters suffering from a lack of solar 
activity, 40 meter activity has been picking up. 


The PCC's 85-105 comments on international ard 
party traffic has also put a bind on some interes- 
ting HP developments. A number of Europeans 
(particularly LA and OL) had been using U.S. BBS 
stations for intra- European forwarding. European 
countries have historically forbidden third-party 
traffic, but apparently they don't interpret 
amateur-to- amateur comaunications (even involving 
an intermediary) as involving a third-party. No 
one has asked for a ruling on this dilemma (Please 
don't! The answer is likely to be what you don't 
want to hear!) and as a result thermodynanics 
applies and entropy increases. My advice to the 
HPers would be to be very cautious about allowing 
any BBS traffic not involving countries which 
permit third-party traffic. 


NEW SOFTWARE RELEASE FOR TNC-2 


A new software release is now available for the 


TNC 2 and clones (PK-80, TNC-2A, TNC-200, MPJ- 
1270). 
Release 1.1.3 corrects the full-duplex bug in 


1.1.2 and provides two new features. 


RXBLOCK allows the TNC to pass information fron 
the packet channel in a format more suitable for 
BBS and other automated operations. 


A number of counters are grouped under the 
command, providing status 
TNC's performance. 


HEALTH 
on the link and the 


If you wish to upgrade you may send your old 
270286 EPROM to TAPR, inserted in anti-static foan 
and mailed in a small carton. Enclose $1.00 (one 


dollar) and return postage. Your EPROM will be 
erased, reprogrammed and returned to you. (If the 
EPROM is laproper Iy packaged or damaged, it will 


NOT be reprogranned.) 


Alternatively, you may purchase a new. programmed 
BPRON from TAPR for $10 postpaid. 


Please mark all requests with “TNC 2 Software 
Update” on the outside of the carton or envelope. 
This will help us process your order faster. 


Thank you! 


DIGIPEATERS, NETWORKING and BBS FORWARDING 


We are now starting to see rudimentary Level 3" 
networks being tested on the air in several loca- 
tions. Until these get running, we have only two 
types of networking available: digipeaters and BBS 
linking. With the large influx of new packeteers, 
multi-hop digipeater links are becoming impossible 
to use. This is easy to understand -- it is due to 
QRM; our packet radio channels are becoming very 
congested. Although up to 8 digipeaters are 
“legally” permitted in AX.25, pragmatism would say 
that any more than two are unworkable. This can be 
shown to be the case mathematically. If N digi- 
peaters are used in your point-to-point link. then 
there are 2*(N+1)}) separate transmissions (counting 
the required ACK). If the probability of a packet 
getting thru on any one of those one-way links is 
P, then the overall probability of a packet making 
it thru the link and the ACK coming back is Po = P 
2 (2*N+1)}. 


The overall probability Po of making it is 
tabulated below for all the permitted numbers of 
digipeaters and different quality links: 


| cecce Per Hop Link Probability ----- 


# Digis {| 0.5 0.7 0.8 0.9 0.95 
0 } 0.25 0.49 0.64 0.81 0. 90 
1 1 0.06 0.24 0.41 420.66 £0.81 
2 | 0.16 0.12 0.26 0.83 0.73 
3 } 0.004 0.06 0.17 0.43 0.66 
4 | 0.001 0.003 0.12 0.35 0.60 
5 { - 0.001 0.07 0.28 0.84 
6 ö - - 0.04 0.23 0.49 
7 | - - 0.03 0.18 0.44 
8 | - - 0.02 0.15 0.40 


Admittedly. a model which has all hops with equal 
probabilities is only an approximation but the 
conclusions still seem valid. First. If you have a 
total Po of 0.25, then on average you will require 
1/0.25 = 4 retries to get you packets thru. My 
experience would indicate that a lot of paths have 
per hop relfabflities of 0.7 and less. Anyone 
attempting to use multiple digipeaters under such 
conditions should be tmmediately branded a PLID 
(Packet LID). The 0.8 column seems to fit east- 
coast experience for 145.01 at about 8PM in the 
evening. By about midnite, 0.9 seems to to be the 
case on 145.01. Most of our localized LANs (like 
145.05 in the Balto/Wash area, where most people 
hear everybody else) also seem to be around 0.9. 
High quality links on 145.01 at 3AM approach the 
0.95 case. 


My assertion {is that packet activity comes to a 
grinding halt, users start cursing each other and 
delays seem interminable when the overall prob- 
abilities get below about 0.6. Therefore I con- 
clude that (except for the exceptional case of 
0.95 quality links), using any amore than 2 digti- 
peaters is a waste of time. Of course the reasons 
that this is true are twofold: (1) LAN Users are 
operating on the same frequencies as used for 
inter-LAN communications, and (2) Digipeaters are 
DO NOT constitute a “real” network. 


The former will be solved by developing and inple- 
menting dual- or multi- port network nodes (that's 
what the Xerox 820 & TNC2 Oual-port digipeaters. 
the TAPR NNC. etc. are all about). The second 
requires the concurrent development of real net- 
working software and protocols (and that's what 
“Level 3“ is all about). Both of these activities 
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require a lot of hard work to do the development, 
and then will require a sizeable financial invest- 
ment to implement. You can help out by supporting 
groups like TAPR (to develop the NNC) and your 
local packet organization (to implement new 
systems to bring these capabilities to your area). 


Until that time, the closest thing we have to a 
network is the ad hoc group of linked BBSs. This 
is a non-real-time network that forwards your 
messages towards their final destination, rather 
like the Pony Express. In the northeast. we now 
have reliable links extending from Richmond VA 
north to Ottawa, from Maine west to Ohio. The nora 
is for maii deposited in Washington in the evening 
to be in Boston the following morning. To the 
south, a similar network exists covering Florida, 
Georgia, Alabama and South Carolina. The.northeast 
and southeast still have to relay on HP packet 
activity to bridge the gap since we still haven't 
established suitable Links thru southern Virginia 
and North Carolina. Similar stories can be told in 
other areas. 


This network “works” because there are enough 
compatible BBSs to blanket the map, and these 
individual BBSs are only one or two digipeaters 
away from their nearest neighbor. 


DOUBLE DEALING WITH DOUBLEDOS 


As a final topic, I would like to return to the 
IBM-PC (and clone) world and the WA7MBL software. 
Many of us had hoped to use our PC's for tasks 
other than running the BBS: these tasks include 
such mundane but necessary activities as file 
maintenance and perhaps even a little off- line 
computing. One interesting possibility that struck 
several of us at about the same tine was a $50 
software package called DoubleDOS, published by 
SoftLogic Solutions in Manchester NH. Others that 
have been discussed are DESQview, MS Windows, 
Concurrent PC-DOS, etc. 


Several of us started running the 'MBL code with 
DoubleDOS and have had mixed results. While WB2MNF 
reports having had no problems, both KiOJH and I 
found that some sort of “worm” was eating our disk 
files, rendering lost clusters that had to be 
reclaimed with CHKOSK or Norton Utilities. I suf- 
fered on catastrophic DoubleDOS “worm” which ate“ 
ay entire user data file and rendered several nai} 
messages unusable. KIOJH reported similar tales of 
woe. When DoubleDOS was killed, the problem went 
away. I contacted the folks at SoftLogic and found 
then to be helpful. White they never would adait 
that their program could be hungry“, they allowed 
as how the latest release of DoubileDOS, Revision 
U. might solve my problem. They told me that if 1 
would send them a blank disk, they would send out 
their latest “Revision U“ code to me right away. I 
installed the new software and (knock on wood!) 
the problem seems to have gone away. After a 
couple of weeks of use, the only time I had any 
problem was when I had both partitions writing to 
the same file -- this 18 definitely a forbidden 
thing. But used with care, DoubleDOS does seem to 
work with the ‘MBL 2.04 code. at least for me. 
Caveat emptor! 


To get the Rev. U update disk from SoftLogic 
(registered, legit owners only!). send a blank 
disk and return mailer to: 
Mr. Silver 
SoftLogic Solutions 
330 Chestnut St. 
Manchester NH 03101 
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TAPR AND THE FCC 
PR Docket No. 85-105 


Harold Price 


TAPR and its members have been actively supporting 
all areas of packet development since the early 
days. As we've seen, this involves far more than 
just hardware and software developnent. We pro- 
duced extensive documentation. We spread the word 
with articles in Ham Radio. 73, and QST. We 
supplied speakers at ham gatherings large and 
small, The only area we had neglected vas the 
regulatory arena. Although members of TAPR have 
always been on the ARRL Ad Hoc Digital coasunica- 
tions Committee, we had never presented our 
opinions directly to the FCC as the countries 
largest packet specialty group. At the board 
meeting in February. the directors resolved to 
become more active in this area. 


The following is our first efforts in this area, a 
petition to the FCC for reconsideration of 
proposed new language in the amateur rules that 
prohibits automatic retransmission of 3rd party 
traffic. We will continue to participate in this 
and other regulatory actions that effect the 
future growth of amateur digital communications. 
Members are invited to make their views known by 
sending comments in to the TAPR office or to any 
director via packet or Compuserve's HAMNET. 


Before the 
Federal Communications Commission 
Washington, DC 20384 


In the matter of Amendment ) 

of Part 97 of the ) PR Docket No. 88-105 
Commission's Rules to ) 

permit automatic control of) RM-4879 

amateur radio stations. ) 


PETITION FOR RECONSIDERATION 
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Filed by: 

Tucson Amateur Packet Radio 
P. O. Box 22888 

Tucson, Arizona 85734 


To the Comsaission: 


Tucson Amateur Packet Radio, a club with inter- 
national membership consisting of 1400 amateur 
packet radio enthusiasts which has coordinated the 
volunteer developnent of many of the major build- 
ing blocks of the existing amateur packet network, 
and whose members have contributed since 1981 in 
the development of packet radio hardware, soft- 
ware, and operating procedures, hereby submits 
this petition for reconsideration of the report 
and order on PR docket No. 85-108. Our comments 
are limited to activities and operation above 30 
MHz, as 85-105 only addresses these frequencies. 


Our reasons for requesting a reconsideration are: 


1) The tnclusion of third-party traffic limita- 
tions, given the current definition of third-party 
traffic, puts severe constraints on the design and 
utilization of the developing packet radia 
hetwork. 


The questions that arise fn the amateur packet 
community over this issue are mainly semantic 
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ones, caused by attempting to force new tech- 
nologies to fit the old definitions supplied by 
97.3. The PCC has stated both at amateur gather- 
ings and in the comments associated with several 
recent actions that it is interested in promoting 
conputer asaisted amateur communications and what 
is commonly referred to as Conputer-Based-Message- 
Systems (CBMS), or Bulletin Board Systems (BBS). 
Bulletin Boards are central repositories of mes- 
sages sent between two or more parties. The mes- 
sages are stored for indefinite periods of time on 
the bulletin board until they have been read by 
ail parties concerned. The messages are seldom 
sent on behalf of the control operator of the BBS 
itself. and that's where the third-party rules 
begin to cloud the issue. 


By strict application of the current definition of 
third party traffic 


97.3(v) Third party Traffic. Amateur radio 
communication by or under the supervision of 
the control operator at an amateur radio 
atation on behalf of anyone other than the 
control operator. 


A digital BBS system under automatic control could 
not transmit messages stored on it that are not 
originated by or destined for the control operator 
of that BBS. This makes illegal the major purpose 
of the bulletin board systen. 


During the early development and on the air test- 
ing of packet radio message systems, amateurs have 
viewed the message relay device as a repeater. A 
repeater, as defined by 97.3(1), is a device that 
aatomatically retransmits the radio signals of 
other amateur radio stations. Part 97 does not 
specify a minimum length for the time delay 
between receipt of the radio signal and its 
retransmission. 


Repeaters, as commonly used, can pass traffic 
between two amateurs, neither of whom are control 
operators of the repeater, with out having that 
traffic defined as third-party. Repeaters have 
regulatory limitations of their own, however, and 
the development of more complex message syatens 
and other packet switching devices will soon pass 
beyond the liaits of the current definition of 
“repeater”. 


Bxisting amateur BBS systems are already handling 
large numbers of messages. Recent statistics 
reported by east coast stations show counta of 
more than 1000 messages per month at each of 
several sites. These systems are developing more 
sophisticated methods of automatically forwarding 
messages from site to site. 


To review, the language specified by 85-108, makes 
the BBS function, desired by both the amateur 
population and the FCC, illegal unless the BBS is 
classed as a repeater. Imminent developments in 
packet radio will make this classification invalid 
for some devices under the current definitions. 
Therefore, 85-105, while attempting to permit 
continued experimentation, actually inhibits it. 


A fix for this problew could be to include lan- 
guage in part 97 that specifically states that 
traffic originated by an amateur station on behalf 
of an amateur and destined for an amateur is not 
third-party traffic. This would make the permitted 
activities of automatic control digital devices, 
serving in a relay capacity but not classified as 
repeaters under the current definitions, match the 


permitted activities of classic repeaters. We note 
that several countries which prohibit third party 
messages {including West Germany, Norway, Japan 
and New Zealand) have chosen the interpretation 
that amateur-to-amateur messages passed thru 
packet radio SBS networks do not constitute third 
party traffic. 


2) The inclusion of third-party traffic restric- 
tions, for traffic of a character not discussed in 
1) above, will severely limit the utility of 
packet radio networks for public service 
applications. 


The following discussion presumes the acceptance 
of the above argument, and that the type of third- 
party traffic discussed is traffic on behalf of 
someone other than the control operator of the 
origination or destination station. 


The FCC has done much to promote the use of high 
speed digital communications in the amateur ser- 
vice. The constant growth of experigentation in 
packet radio began when the use of the ASCII code 
at speeds of 300 bps and more were permitted. The 
majority of digital communications currently takes 
place at 1200 bps. 9600 bps is in limited use now, 
with S56kbps devices under construction. 


A requirement that third-party traffic be non! 
tored at each relay point in the network will 
limit the speed of the network to that of the 
reading speed of the slowest control operator. It 
would probably force the construction of two par- 
allel networks, one at low speed for third-party 
traffic, and one at high speed for non-third-party 
traffic. This 1s undesirable. 


The requirement to monitor the traffic at each 
relay point in the network also places severe 
constraints on the design and implementation of 
the network. In most of the networks now under 
discussion, the message is only guaranteed to 
appear in its entirety at its entry to the net- 
work, and at its exit. While the message 1s in the 
network, it is broken into many smail pieces. They 
may be out of sequence as they pass a relay point. 
Some parts of the message may take a different 
path through the network. 


With such message fragmentation, a control opera- 
tor at an intermediate relay point may not have 
sufficient information as to the content of the 
message being relayed to correctly judge whether 
the character of the message is that of third- 
party traffic or not. 


On the other hand, TAPR and its members share the 
FCC's concern over potential abuse of the network 
by commercial interests. The problem then becomes 
one of making sure the amateur regulations are 
followed, while at the same time making it 
possible to build the network. 


We belteve that it 1s possible to meet both of 
these goals. The key is in treating the packet 
radio network, consisting of an unspecified number 
of relay stations, as a “pipe”. The pipe has an 
input and an output. At the entrance and exit to 
the pipe are non-automated contro] operators, who 
are ensuring compliance with the rules. Once a 
message has been placed in the pipe by a control 
operator, it need not be rechecked by an operator 
at each relay point that makes up the pipe. The 
message is again checked by a control operator at 
the end of the pipe if it is destined for a third- 
party. The amateur who was the control operator at 
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the origination point of the message is respon- 
sible for ensuring compliance with the rules. 


We cite as an example: Assume that a network 
exists between San Francisco and Los Angeles. 
There are two parallel paths in this network. one 
that runs down the coast at 9600 bps on 221.95 
MHz, and a second that runs via Sacramento through 
the central valley. An earthquake simulation is 
taking place between the Red Cross in San 
Francisco and the State Office of Emergency 
Services (QES) in Los Angeles. The Red Cross has 
entcred a series of damage reports and hospital 
bed estimates into a hand-held computer. There are 
40,000 characters of data involved. They hand the 
computer to an amateur to transmit the data to Los 
Angeles over the amateur packet network. This is 
obviously third-party traffic. It is also obvious- 
ly something that could not have been sent using 
voice, Morse code, or other slow data rate modes, 
in less than five hours. 


The amateur in San Francisco reviews the data and 
determines that it meets the amateur rules and 
regulations. He then, as control operator of a 
station attached to the entry point of the net- 
work, (the pipe), enters the data into the 
network. It now flows through the pipe toward Los 
Angeles. Also in the pipe, simultaneously, are 
perhaps 20 other two way conversations. Monitoring 
of the messages while in transit through the pipe 
is diff tcult to do as it flows at high speed 
through two different paths. Part of the messages 
Bay even be automatically stored on disk at an 
intermediate point if the Los Angeles end of the 
network is down or congested. Once the message 
traffic is in Los Angeles, the control operator of 
the station at the final destination reviews then 
before passing them to the third-party. 


A question that will certainly be raised at this 
point is, “Is this actually likely to occur in the 
near future?” Yes. The predecessor to the network 
above exists now. There are 5 relay points along 
the coast between Los Angeles and San Francisco 
operating on 145.01 MHz at 1200 baud. There are 4 
relay points that go up the central valley on 
145.05 MHz at 1200 baud. During an exercise with 
the State O£S, amateurs were handed a disk from an 
Apple II computer which contained simulated third- 
party traffic. This traffic was relayed through 
the network to an attended BBS system in San 
Francisco where it was stored and later transmit- 
ted through a second network to Sacramento. Simi- 
lar networks and public service drills exist in 
other areas of the country. Large networks exist 
in the New England area, the Mid-Atlantic States, 
and in Plorida. 


The only thing missing between the imaginary 
scenario and the actual one Is higher baud rates 
and an increased level of automatic control. Both 
of those elements will be required if the amateur 
network is to provide a high level of service and 
reliability tn time of need. 


To review, we suggest that the network be viewed 
as a pipe, and that contro] operators at the input 
and the output to the pipe are sufficient to 
ensure compliance with third party traffic 
regulations. 


At no time do we recommend that the third parties 
themselves be given direct access to the network. 


The question of unauthorized, i.e. commercia!, 
access to the network must be discussed. Since the 


regulations for traditional non-digita! repeaters 
do not require constant monitoring. neither should 
the elements of a digital network. The only moni- 
toring required for repeaters under automatic 
control] is when third-party traffic is involved, 
this topic is discussed above. Monitoring does go 
on, however, in the course of daily amateur 
activities. 


Policing of the amateur frequencies to keep intru- 
ders out has always had a great deal of support in 
the amateur community, and high speed digital 
communications will be no different. Although the 
same things that make it hard to monitor third- 
party traffic “in the pipe” will also affect an 
intruder watch, the intruder must still use the 
same pipe input as everyone else. Here, monitoring 
is easy. In fact, at its simplest level, packet 
radio is the enbodlaent of the FCC's underlying 
requirements for automatic control, “devices must 
be installed and procedures must be implemen- 
ted. The network entry and exit points are 
rigidly controlled by the protocols inherent in 
packet radio. Although the particular procedures 
will change as the network evolves, their attri- 
butes will remain the same. The originating and 
destination station are readily discernible. 
Activity is easily monitored and tracked by a 
computer. The devices necessary to do this moni- 
toring will be readily available, since they are 
the same devices used by the general amateur popu- 
lation for access to the network. The prices of 
such devices have fallen from $500 to $99.00 in 
three years as the number of amateurs using the 
mode rose from 200 to 14,000. 


In summary for point 2}. we believe that a 
requirement to monitor third-party traffic at each 
relay point in the network places such severe 
constraints on the design and inplerentation of 
the network as to bring the feasibility of con- 
struction of such a network into question. The 
alternative of making the network off-limits to 
third-party traffic would be to fall far short of 
the requirements of 97. 10a). 


We believe that this problem can de fixed by 
adding a clause to the new 97.80(b) as follows: 


lüb] No amateur station may be operated under 
automatic control while transmitting third-party 
traffic) 


unless that station is serving in a relay role 
in a network of digital stations where the 
traffic was originated at a station not under 
automatic control. 
when traffic 18 


and elsewhere third-party 


discussed. 


TAPR wishes to thank the FCC staff for their 
obvious interest in amateur packet radio and its 
continuing development. 


/s/ 


Dr. Thomas A. Clark. W3IWI, Director 
for Lyle Johnson, WA7GXD. President 
Tucson Amateur Packet Radio 

P.O. Box 22888 

Tucson, Arizona 85734 
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MINUTES OF THE TAPR BOARD OF DIRECTORS MEETING 


Sunday, 09 February. 1986 


The following Board nenbers were present: 

Mike Brock, WBGHHV, Tom Clark, W3IWI, Peter Eaton, 
WBOPLW, Andy Freeborn, NOCCZ, Steve Goode, K9NG, 
Eric Gustafson, N7CL, Skip Hansen, WBG6YMH, Lyle 
Johnson, WAT7GXD, Harold Price, NK6K, Scott 
Loftesness, W3VS. Dan Morrison, KV7B, Margaret 
Morrison, KV7D, Bill Reed, WDOETZ, Gwyn Reedy. 
WIBEL, Pat Snyder. WAOTTW. 


The following 
invitation: 
Mark Baker, Heather Johnson, Terry Price. 


observers were present by 


The meeting was called to order at 0836 hrs by 
Lyle Johnson. 


OLD BUSINESS 
1) Terry Price distributed the financial report. 


2) Andy Freeborn moved that the financial report 
be accepted. Tom Clark seconded and the motion 
carried unaninously. 


3) The EI Paso shuttle project was explained. A 
letter will be written to attempt to recover 
some of the cost. 


4) Tom Clark moved the Board express its thanks 
to Terry for her work in preparing the TAPR 
financial reports and assisting in developing 
procedures for the office. Andy Freeborn 
seconded. and the motion was carried 
unanimously. 


3) Lyle Johnson raised the question of the 
timing of future financial reports to the 
Board, monthly or quarterly. Bill Reed moved 
the reports be provided monthly. Pete Eaton 
seconded and the motion carried unanſgous ly. 


6) Harold Price questioned the level of capital 
equipment and suggested a reduction by means 
of selling excess items. The results of the 
discussions were: 


Xerox 820 board, power supply, disk drives and 
Yaesu radio will be tntegrated by Eric 
Gustafson for a mailbox facility in Tucson for 
NNC and other experimentation. 


The Radio Shack Color Computer syatem and VIC- 
20 will be disposed of. 


NEW BUSINESS 


7) Nominations were opened for officers to serve 
until February, 1987.Andy Freeborn nominated 
Lyle Johnson for President. Dan Morrison 
nominated Pete Eaton for Executive Vice Presi- 
dent. Tom Clark nominated Heather Johnson for 
Secretary. Tom Clark nominated Terry Price 
for Treasurer. All nominated were elected 
unanimously. 


8) Lyle Johnson polled all Board members to 
state their impressions, and asked what goals 
TAPR should focus on. The discussions that 
followed included the perception of TAPR by 
others. The results of the poll were three- 
fold. TAPR should take a stand on regulatory 


issues; direct attention to matters of Infor- 
mation dissemination; and support projects to 
advance the state of the art in Amateur packet 
communications. 


9) The meeting adjourned for a 10-minute coffee 
break at 1040 hrs. 


10) The meeting resumed at 1050 hrs. 


11) Tom Clark proposed the goal of tmproved infor- 
mation dissemination be served in part through 
setting up a “TAPR Special Interest Group” on 
@ commercial computer information system to 
provide: 

a) electronic mail/messaging services; 
b) software exchange; 
c) “real-time” publications; 


with the eventual goal that such service be 
moved to packet radio as fast as practical. 


A committee consisting of Tom Clark. Pete 
Eaton and Scott Loftesness was formed to 
investigate this and report back to the Board 
in the next thirty days. 


12) A general discussion then ensued regarding 
budgets and fixed costs. Action was tabled 
until after the lunch recess. 


13) The Board adjourned for lunch at 1145 hrs. 
14) The Board reconvened at 1315 hrs. 


15) Scott Loftesness proposed that the Board 
create committees and suggested technical, 
regulatory and administrative be formed. The 
Board approved of a Regulatory/Coordinating 
Committee. Scott Loftesness, Dan Morrison, 
Tom Clark and Harold Price volunteered to 
serve initially. 


16) A discussion followed on the establishment of 
a Project Review Committee to review and re- 
commend projects for Board approval of fund- 
ing. Pete Eaton suggested that the committee 
be made up of Board members and TAPR members- 
at-large to help open the project cycle to a 
wide range of views. Creation of this commit- 
tee was tabled until later in the meeting. 


17) Scott Loftesness moved the Board provides the 
President with discretionary spending authori- 
ty not to exceed $1,000 per occurrance without 
prior approval by the Board. Tom Clark secon- 
ded and the motion failed: the vote was } for 
and 14 opposed. 


18). Harold Price moved that the Officers have 
thirty days to propose an operating budget to 
the Board.Scott Loftesness seconded and the 
motion carried unanimously. 


19) Tom Clark moved the Board constitute itself as 
a standing committee of the whole to use elec- 
tronic mail for the purpose of voting witha 
seven day response period after a question is 
called. Gwyn Reedy seconded and the motion 
carried unanimously. 


20) A discussion followed regarding conflict-of- 
interest concerns. 
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21) 


22) 


23) 


24) 


25) 


26) 


27) 


29 


30) 


31) 


32) 


A ten-minute break was called at 1515 hrs. 
Director Loftesness left for the airport. 


The Board reconvened in camera at 1525 hrs 
with Director Reedy absent at the Board's 
request. 


Director Reedy and non Board members returned 
to the meeting. The Board announced that "In 
the matter of a conflict of interest of a TNC 
manufacturer serving on the Board of Directors 
of TAPR, the following resolution was voted 
on: ‘The Board expresses confidence in Gwyn 
and takes no further action.’ The resolution 
was passed by secret ballot. 7 to 6. 


Pete Eaton discussed the AMRAD PC-PAD project 
and reported a cost of approximately $2,000 
would be incurred to bring the project to 
prototype stage. 


Tom Clark moved the Board allocate 82.000 to 
fund the AMRAD PC-PAD project to the prototype 
stage. The motion was seconded and failed to 
pass; the vote was 1 for and 13 opposed. The 
Board suggested the project be submitted via 
the proposed Project Review Committee to fur- 
ther assess the need for such a device by the 
packet radio community and to deternine if 
sufficient resources are available to ensure 
the successful conpletion of the project. 


Tom Clark and Lyle Johnson briefly reviewed 
the SAREX 2 project to carry packet radio 
aboard the Space Shuttle. Total expenses to 
date are $885. 


Harold Price moved the Board establish a 
Project Review Committee be established to 
evaluate new project proposals and submit them 
to the Board for approval. Gwyn Reedy secon- 
ded and the got fon carried unaniaously. 
Harold Price, Lyle Johnson and Tom Clark vol- 
unteered to serve on the committee. The Board 
also directed that the comaittee be made up of 
members-at-large. said members to be tenpor- 
arily appointed for review of projects in 
their area of expertise. 


Harold Price aoved no new projects be estab- 
lished without Project Committee approval. 
Mike Brock seconded and the motion was carried 
unanimously. 


Gwyn Reedy moved the Board accepts the SAREX 2 


project with a total budget of $1,000. Pete 
Eaton seconded and the motion carried 
unaalimously. 


Lyle Johnson explained the present status of 
the TNC tuning indicator project. Lyle volun- 
teered to be project manager and the Board 
directed him to make a proposal and submit it 
to the Project Conmittee. 


Steve Goode discussed a possible 9600 baud/56 
kilobaud radio project. Tom Clark moved the 
Board accepts Steve's presentation at the 
Annual Meeting as the framework for a proposal 
to develop a 9600 baud RF deck and approves 
interim spending authority for $1,000. Pete 
Eaton seconded and the motion carried 
unanimously. 


Tom Clark raised the issue of a Packet Soft- 
ware Fxchange. ft could: 
a) provide a coordinated channel! 
software to the public: 
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33) 


34) 


35) 


36) 


37) 


38) 


39) 


40} 


41) 


42) 


d) address the costs of development and 
distribution; 

c) provide some sort of subscription basis 
for rapidly evolving software; 

d) require a project manager to coordinate 
activites of cloners and developers; 

e) provide focus of activities; 

f) minimize dilution of effort; 

g) provide limited funds to reimburse soft- 
ware developers for real out-of-pocket 
costs. 


In the discussion that followed, the Board 
determined that the idea was a good one with 
excellent possibilities. It further deter- 
mined to table the issue for the time being 
and continue discussion on electronic mail 
over the next asonth. 


Pete Eaton advised a local volunteer, Gene 
Piety, had offered to assist in the office. 
The Board requested Pete contact Gene and 
accept his offer. 


Lyle Johnson asked if the office lease should 
be renewed for six months or one year. The 
Board voted for a one year renewal. 


Pete Eaton read a letter from Gene Piety pro- 
posing that TAPR purchase a repeater from Wes 
Morris, give up the coordinated frequency pair 
of the repeater, convert the repeater to a 
digipeater operating on 145.01 MHz and turn 
the site into a beta test site for the NNC 
project. The Board restated that TAPR is an 
organization with international membership and 
cannot be involved with direct support of 
local RP sites. TAPR will continue to do dev- 
elopment of packet radio. 


The Board determined that requests for loaner 
gear for development projects (eg, software 
development) need to be submitted to the pro- 
posed Project Review Comaittee on a case-by- 
case basis. The Board further directed that 
any loaner gear should have a tag identifying 
it as TAPR property, and that the borrower 
should sign a receipt for the gear. 


Dan Morrison and Eric Gustafson reported they 
are undertaking a project to develop an opti- 
mized 300 baud HF modem utilizing a digital 
signal processor, working in conjunction with 
Mike Parker, at no cost to TAPR. They will 
write an article in PSR about it. 


Lyle Johnson mentioned discussions with Sky- 
Link Corporation regarding a high-speed, high 
spectral-efficitency modes for packet use. 
Steve Goode excused hiaself from the discus- 
sion for conflict-of-interest reasons.The 
Board directed Lyle to proceed with discus- 
sions with SkyLink. 


The existing 9600 baud modem project was dis- 
cussed. A poll should be taken on DRNET to 
see if more boards are needed. 


The FAD board was discussed. The Board auth- 
orized an additional] 50 boards be fabricated. 


RUDAK and JAS-1 modems were discussed. No 
cost information was available and the pro- 
jects were referred to the Projects Committee. 


Lytle reported on the NNC project The NNC Pro- 
ject will be written up and submitted to the 
Board via the Projects Committee. 

Continued on page 15. 
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PROJECT PROPOSAL GUIDE 


Have a good idea that will be useful to the packet 
community? Perhaps you want to develop some spe- 
cialized applications software, or a better modem? 


If 30. TAPR is interested in helping you! 


The Board of Directors set up a Prejects Committee 
to provide a channel to assist you in presenting 
your ideas to apf for various packet- related 
projects. 


The following may be used as a guide for preparing 
a project proposal for TAPR. Please follow these 
guidelines, and submit any proposal with at least 
three copies in addition to the original. You may 
send your proposal to 


TAPR 

PO Box 22888 

Tucson AZ 85734-2888 
Attn: Projects Conmlttee 


Thank you! 

000 

Date: Self-explanatory. 

Title: Provide a descriptive name for the pro- 
ject or proposal. For example, “HF 
Tuning Indicator“. or “Ten-Dollar TNC”, 
etc. 

Purpose: Provide a brief statment of the primary 


goal (or goals] of the project. 
Project Manager: 


Give the name, call, address and 
telephone number of the person who will 
be responsible for overall project. 


Estimated development cost to prototype (s): 


Most projects invovle some sort of cash 
outlay to get started. Printed Circuit 
boards may need to be layed out and 
fabricated, or parts purchased, or 
special equipment rented to obtain some 
data. Indicate also how many prototypes 
may be needed to verify the operation of 
the final unit or device or progran. 


Estimated direct cost per unit: 


In the event nultiple units are expected 
to be produced (such as a tuning indica- 
tor or digital radio), provide a fairly 
close idea of the cost for parts and 
outside services that may have to be 
purchased or contracted. 

Estimated time to develop prototype: 

If the project is accepted for TAPR 

sponsorship, how many weeks will elapse 

before a prototype is available to test? 


Estimated time from prototype to distributable 
“product”: 
If the project is something to be 


produced for sale {such as a tuning 
indicator), rather than an investigation 
(developing -an algorithm to- measure 
channel efficiency, for example) how 
many weeks should it take to test and 
debug the unit to the point that it can 
be made available to other packeteers? 
Estimated overall demand: 
Again. in the case of a device intended 
to be distributed (this includes soft- 
ware, for example). how many devices may 
be reasonably expected to be produced? 
Will; this benefit a small number of 
packeteers, or a large cross-section of 
the Amateur packet community? 


Estimated rate of distribution: 


Again, in the case of something to be 
generally in demand, at what rate should 
we expect to produce them? One hundred a 
month, or one a day. or 222 


Estimated cost to go from prototype to initial 
stock: 
Please include such things as startup 
costs, testing. packaging. level of 
initial stock, printing, and other de- 


tails that require monetary resources. 
Detailed Project Description: 


Provide a fairly detailed description of 
the project in terms of its proposed 
implementation. Optional features and 
their relative merit versus cost to 
develop and/or produce, etc.. should be 
spelled out. Explain why the proposed 
project will be interesting to a packe- 
teer. 


Also include a specific statement as to 
how this project meets TAPR's stated 
goal “to advance the state of the art in 
Amateur packet communications"? (in 
other words. why should TAPR fund it?) 


Detailed Project Budget: 


How much will it cost, line item expen- 
ses for parts (broken down by part cate- 
gory or finer), expenses for startup. 
and the like. 


Detailed Project Timeline: 


Here include financial milestones, deve- 
lopment milestones (including written 
material for project support, etc.) and 
any other time-related functions you 
think are applicable. 


Other comments: 


Here is your chance to cover issues not 
specifically required above. 


Submitted by: 


—— 2 ——— — 2 — 


77... eeeee e ———.—— — PSR QUARTERLY 


BEGINNER'S CORNER: 
STATE MACHINES , PART 1 


Lyle Johnson, WA7GXD 


“Il read in my TNC 2 manual that a State Machine is 
used to convert NRZI to NRZ! What is NRZI. why 
should it be converted, and what sort of states 
does this thing machine, anyhow?" 


1 have been asked many times to explain what a 
state machine is and how it works, so with this 
issue of PSRO I will give you some background. 
Next time, [ will attempt to explain the inner 
workings of a state machine in non-technical 
teras. 


The best place to begin is at the 
here goes! 


beginning, 80 


The AX.25 protocol (rules of operation) declare 
that packets will use a coding scheme called Non- 
Return to Zero - Inverted (NRZI, pronounced nur 


zee"). This is no big deal. except most serial (a 
bit at atime, like Morse code] communications 
devices speak ina format called Non-Return to 


Zero (NRZ. not pronounced!), and the two forms are 
not compatible. 


The first generally used packet controlter, deve- 
loped by the Vancouver Amateur Digital Comnmunica- 
tions Group (VADCG, often pronounced “vad*-kig"). 
used an Intel 8273 chip in the radio port circuit- 
ry. and this chip spoke NRZI rather fluently. The 
TAPR Beta board and TNC 1 used a Western Digital 
1933 chip for {ts radio port. which also happened 
to speak NRZI quite well. 


As it turns out, NRZI-speaking chips also happened 
to be quite expensive in those pioneering days of 
1979-1982. This led to the rise of the “software 
approach” crowd, which decried the use of such 
expensive bits of plastic and sand. Instead, they 
programmed their microcomputers to speak NRZI. and 
all the rest of what happens in a packet protocol. 


When TAPR set out to design the TNC 2, one 
was quite clear - the new TNC had to be very 
inexpensive. Another thing was equally clear 
the new unit had to support radios and modems that 
could run at least eight times faster than the 
standard 1200 baud radios and modems in common 
use. In this way, the TNC would remain useful as 
packet matured. No software approach systems with 
the power to do this seemed available within the 
constraints of the budget. 


issue 


Now, you may have heard the term HDLC - it means 
High-leve]) Data Link Control, and it is also a 
part of AX.25. Fortunately, there are lots of 
chips around which support HDLC, and are very 
inexpensive. Unfortunately, they don't also speak 
NRZI. Thus, we were faced with a dilemna. We 
wanted a hardware controller for speed and flexi- 
bility. but we weren't willing to pay more’ than 
three or four dollars for it. (The 8273 sells for 
about $30 and the 1933 for about $20.) 


As it turned out. Zilog made a chip called the 
810. This chip speaks HDLC, and it also speaks 
regular old asynchronous to boot! By asynchron- 
ous, or async, I mean the norma} sort of = start- 
stop characters that a computer or terminal uses. 
We use this means to communicate between the TNC 
and the computer in a typical packet station. For 
four bucks we had replaced two chips needed in 
earlier TNC designs! ö 


Ah. but how to make this beast speak and under 
stand NRZI instead of RRZ 


Paul Newland, AD7I, came up with the solution used 
in the TNC 2. He used a siaple flip-flop to 
change NRZ to NRZI. and a state-machine to go the 
other way. from NRZI to NRZ for receiving. As 
usual, it is easier to generate this stuff than to 
decode it! 


(Now, to be fair, Jon Bioom., KE3Z, had developed a 
similar state machine to use with the Xerox 820 
board for packet use. as had Skip Hansen. WBGYMH. 
The technique isn't particularly new, but it is 
not widespread either.) 


Let's take a look at the difference bewteen NRZ 
and NRZI. Perhaps this will give us a clue as to 
how to convert between then. (If it doesn't now, 
it probably will later...) 


With NRZ encoding. a logical level corresponds to 
a value of "1" or o“ (in digital things, only a 
one or a zero is allowed). This is like the old 
mark and space of RTTY. In the case of a radio 
signal, a high pitched tone means one value, and a 
lower-pitched tone means the other value. Siaple, 
eh? 


Too sinple. 
of another article (slipped that one by. I 
NRZI was conceived. 


For reasons that gay be the subject 
did), 


During the time that a “bit" (a binary one or 
zero) is sent, NRZI decrees that a change in 
levels (or tones, in the case of our present 
packet gear) means a 0“ and no change means a 


8 
Say what? 


In other words, if the tone stays low fora cer- 
tain amount of time, a one was sent. Or if the 
tone stays high, a one was sent. On the other 
hand, if the tone switches (high-to-low or low-to- 
high, it doesn't matter), a zero was sent! 


Clear as mud? Maybe the illustration below will 
help. It shows the sequence 0“ “1" "1" "0" "1" 
in NRZ and NRZI. Remember, we are talking about 
sending information one bit at a tine. soa time 
reference is also shown. 


Value 0 1 1 0 1 

Time i I i H I I 

NRZ :: „ 

NRZI ma ee ee . 
Notice that the value is determined in the niddle 


of each time period. Also notice how simple NRZ 


is, and how confusing NRZI appears at first 
glance! 
However, NRZ I has clocking information built into 
it, and this turns out to be a very important 
factor. 


With asyne data, a start bit is inserted before 
each character sent. and a stop bit is added after 
each character. This is no big deal is you are 
opnly sending a few characters. but if you are 
sending a lot of information. you add about 25% to 
the time t would take if the start and stop bits 
weren't needed. This is how RTTY is sent. 
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With packet, the assumption is made that a lot of 
data will be sent. This means an extra character 
or two will be needed to "frame” each packet. and 


it turns out that we occasionally adda bit to 
help with the clocking and to maintain something 
we call "transparency." Doing things in this 


manner is called synchronous conmaunications. 


out that if you are sending about 10 
synchronous communications is 
Thus, we don't use 


It turns 
characters or more, 
more efficient than async. 
asyne in packet these days. 


To change NRZ to NRZI for transmitting, we connect 
up a flip-flop (a simple logic element that takes 
up about 1/2 of a 20 cents chip) to our outgoing 
data and a clock of 1200 Hz (to send data at 1200 
baud, our most common speed in packet}. At each 
clock time, we look at our data. If it is a zero, 
we flip the flop (or flop the flip, depending on 
your perspective), while if it is a one, we don't 
flip or flop. This lets us change or NRZ to NRZI 
and mix the clock information into the datain a 
certain way. 


As I mentioned above, generating it NRZI is pretty 
easy - and in this case adds less than 20 cents to 
our four dollar circuit. 


Now, before I explain how a state machine could be 
used to recover our data {and clock, by the way!). 
I need to cover just a bit on the difference 
between synchronous and asynchronous logic. 

I expect most of you reading this article have 
seen a schematic of a logic gate, say an OR gate. 
A two-input OR gate has tow incoming signal iines 
and a single outgoing line. It's functionality 
can be described by means of a truth table. 


INPUT A INPUT B OUTPUT 

0 0 0 

0 1 1 

1 0 1 

1 1 1 
Notice that there is no reference in the table to 
time? If both of ay inputs are at a low. or zero 
level, my output is low. However, if either (or 
both) of my inputs changes to a one, the output 
wil) also change to a one INSTANTANEOUSLY! (Yes, 


I know nothing happens instantly, but in this case 
it might as well be instant.) 


This is an example of asynchronous logic. It 
cares nothing for time and its operation isn't 
related to the operation of anything except its 
two inputs. 


Let's look at this behavior in another way. Below 


we have the two inputs connected to random sig- 
nals, and we have a plot of the output. Time 
marks have been added for reference. 
Tine { i i ; ‘ 
Input a ee oe 2 8 
Input B F Carre Sree are 3 3 
output )J Se ee Rae . 
Again, notice that the output changes in response 


to the input signals only: the time refernece has 
nothing to do with anything in this example. 


Now, let's change our logic gate. Let's add an 
input related to the time signa!s. We'll design 
our circuit so that the gate only looks at the 
inputs at the time ticks. We call this "“strobing” 
or “latching.” The timing signals are then based 
on our “sampling rate.” 


Here is the same pattern as before, but now we 
only “sample” at the time ticks. Notice what 
happens to the output. 


Time 8 i : : i ' 


Input A sit : ; ' 


Ingüut Be ee 
Synchronous 
output : 


Looks a bit different, doesn't {t? It turns out 
that we have to sample things faster than the 
changes at the inputs occur if we want to be able 
to approximate the old. snon-synchronous output. 
It turns out that the sampling clock has to run at 
least twice as fast as the fastest event if we are 
to be certain of capturing every event. 


This is a pretty important concept. 


Another important concept is that of state for 
our purposes, we can say that the conditions of 


all the inputs of a logic circuit, at a given 
instant in time, define the state of that logic 
elrcuit. I know that may seem confusing. but 


stick with me! 


Consider the truth table for the OR gate. It has 
two inputs. There are only four definite condi- 
tions that those two inputs can take. We say it 


can have four states. 


If you ever studied music, you know there are 
eight notes in an octave. A trumpet has only 
three valves, yet those three valves. acting as 
inputs, can define any of the elght notes! (of 
course, unless the trumpet player knows his stuff. 
you may get a different set of eight than you 
anticipated!) The point is that the inputs deter- 
mine the state. 


Well. I've run out of space for this PSRQ. Next 
issue. we'll add some memory to our gate so we can 
remenber past states, then »e II see how a state 


machine its built and how it can recover our clock 
and NRZ data from the NRZI signal we use on 
packet. 73 for now! 


— re 
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Continued from page 11. 


43) A point was made that only thoroughly tested 
information should be printed in the PSR: it 
is imperative that the PSR be accurate. 


44) Andy Freeborn agreed to produce an index of 
articles written in PSR. 


45) Which Hamfests TAPR should be present at was 
discussed. It was agreed that priorities need 
to be set and the Executive Committee will 
prepare a budget in the next thrity days. 


46) Gwyn Reedy wanted to know what constitutes a 
TNC 2 for royalty purposes.After discussion, 
Harold Price goved. and Eric Gustafson secon- 
ded. a PC board is the unit upon which the 
royalty is based. The motion was carried. A 
letter will be sent out to existing OEMs 
clarifying this position. 


47) Bill Reed moved TAPR provide an assembled and 
tested TNC to Jeff Bishop, N7FDS,. to assist 
him in developing packet software for the 
blind. Harold Price seconded and the motion 
carried unanimously. 


48) Lyle Johnson reported that the lawyer retained 
by TAPR has moved into government work and is 
no longer representing TAPR. Lyle was in- 
structed to locate another lawyer. 


49) The subject of publications was raised along 
with membership benefits. Electronic systems 
were targeted for information dissemination. 
PSR should contain TAPR news, TNC support 
information, TAPR projects and regulatory 
issues.Merging with PRM was discussed. It was 
noted that PSR contains no advertising (PRM 
does). Problems with overlapping nembership 
were also mentioned, as were the issues of 
identity and contro}. It was decided to con- 
tinue the discussion by electronic means. 


50) The Board expressed it thanks to Modular 
Mining Systems for its continued support of 
TAPR and Amateur packet radio development. 


51) The Board directed the minutes be published in 
the form of a report in the next issue of PSR. 


52) The meeting was adjourned at 2126 hrs. 


— tate etey 


EDITOR'S NOTE 


This issue of the PSRQ is the smallest af recent 
Issues and it is over one month late. Both of 
these situations are entirely due to your editor 
not applying sufficient time ta get the job done 
right, and are the fault of no one else. I 
apologize for the problems with this issue. 


It is already time to begin collecting material 
for the July issue. Please send your contribu- 
tions in early. especially if there are any sche- 
matics or drawings involved. The preferred form 
for text is via electronic mail (DRNET 12975). 
conpuserve {76576,2003}. People/Link {W1IBE!}. or 
by MS-D0OS/ PC-BOS diskette. Other disk formats 
can be read here only with some difficulty. Last 
choice is typewritten or printed input. Keyboard- 
ing a long article Js time consuming. but that's 
‘better than not getting your contribution. 
Thanks. Gwyn, WIBEL.. 


NOTICE TO ALL TAPR/CLONE 
HF PACKET USERS 


Recently Eric Gustafson, N7CL, and 1 re-examined 
the 300 baud HF modem demodulator circuit and 
concluded that the main reason people have diffi- 
culty tuning in HF packet with the standard 300 
baud modem is that it tunes too critically. We 
have come up with what we think should be very 
close to the optimal performance of the 221! 
demodulator circuit. 


To change the standard 300 baud demodulator cir- 
cuit to this improved version, locate header U34 
on TNC1 and U19 on TNC2. The standard 300 baud 
version of this header contains a 226K resistor 
and a 510K resistor. These should be replaced by 
180K and 750K. respectively. The result of these 
changes is that the tuning range should open up 
from about 10 Hz to around 50 Hz. Thus, you 
should experience reliable demodulation when the 
frequency tuned is within plus or minus 20 Hz or 
so of the true signal frequency. 


We urge ali HF packeteers using TAPR TNCs (origi- 
nal or clone boards] to make these changes as 
soon as possible. We also remind everyone that 
HF is becoming alarmingly crowded, and that unless 
sensible operating practice is followed, the 
channel will be useless. Some suggestions con- 
cerning HF operation are: 


1. Try to keep all packets below 80 characters in 
length. 


2. Set MAXFRAME to 1. 
mission time. 


This will minimize trans- 


3. Avoid multiple connections and digipeated 
packet operation. 


4. QSY away from the standard calling frequencies 
as soon as possible. 


5. Set FRACK to a sensibly long value. 


We hope these modifications improve matters on HF. 
and would VERY GREATLY appreciate hearing fron 
any of you who make this modification and are 
able to compare the new behavior to the previous 
behavior. 


73, 


Dan Morrison, KV7B 
Eric Gustafson, NTCL 
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Two amateurs have been successfully operating 
packet on 160 meters. The following report is 
from Steve Hall, WM6P: 

WKGK, Jerry in Camarillo, CA and I have begun 
tests on 160 meter packet. Results: Excellent. 
100% retry free data exchange at 300 bauds. 
Signal levels over the path were 59+ without 
fading. 

160 meters appears to provide a unique 
capability to link reliably over 100 to 500 mile 
paths. single hop groundwave, 24 hours a day. VHF 
covers the shorter paths if prime mountaintop 
1ocat ions are available. 80. 40. and 20 meters 
provide longer paths (>500 oi). 

Interested? Contact Steve Hall at 664 Bristo} 
Ave. Simi Valley. CA 93065. (805) 526-1120. 
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WEMBERSHIP APPLICATION 


Tucson Amateur Packet Radio Corporation 
P.O. Box 22888, Tucson. AZ 85734 


Callsign: Class: 


——— 2 — 2 — — = 


Address: 
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If you wish to have any of the above information 
not be published in a membership list. indicate 
the items you wish supressed ooo 
I hereby apply for membership in Tucson Amateur 
Packet Radio Corporation. I enclose $12.00 for 
one year's membership dues. I understand that 
$8.00 of my dues are for subscription to the 
Packet Status Register Quarterly (PSRQ). My 
signature indicates that I desire to subscribe to 
PSR and become a TAPR member. 


Signature: Date: 
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The Tucson Amateur Packet Radio Corporation is a 
nonprofit scientific research and development 
corporation. The corporation is licensed in the 
state of Arizona for the purpose of designing and 
developing new systems for packet radio 
communication in the Amateur Radio Service. and 
for freely disseminating information acquired 
during and obtained from such research. 


The officers of the Tucson Amateur Packet Radio 
Corporation are: 


Lyle Johnson. WA7GXD President 
Pete Eaton, WBOFLW Executive vf 
Heather Johnson Secretary 
Terry Price Treasurer 


The Packet Status Register is published quarterly 
for $8.00 by the Tucson Amateur Packet Radio 
Corporation. Second-class postage paid at Tucson, 
AZ and additional mailing offices. POSTMASTER: 
Send address changes to TAPR, P.O. Box 22888. 
Tucson, AZ 85734. Explicit permission {s granted 
to reproduce any material appearing herein. 
providing credit is given to the author and TAPR. 


TAPR membership and PSR subscription mailing 
address: 


Tucson Amateur Packet Radio Corp. 
P.O. Box 22888 

Tucson. AZ 85734 

(602} 746-1166 


PSR editorial submission address: 


PSR Editor, Gwyn Reedy, WIBEL 
812 Childers Loop 

Brandon, PL 33513 

(813) 689-3355 


PACKET STATUS REGISTER QUARTERLY 


TUCSON AMATEUR PACKET RADIO CORPORATION 
P. O. 30x 22888 
TUCSON, AZ 85734 


2nd Class 
Permit Pending 
Tucson AZ 


Check your address label for membership expiration 


date. 


TAPR Membership Questionaire 


The TAPR Board of Oirectors wants to hear from you! There are a few issues that we are faced with at this time that may have 
a significant. long-term effect on your organization. In an effort to better serve you. as wel] as make it easier for you to 
comaunicate your thoughts to us, we have prepared this questionaire. Please take a few moments to respond and mai! in the 
completed form. A generous space has been left at the bottom for your comments. Thank you! 


Please remember that TAPR officers, Directors and other people that make things happen are amateur volunteers just like 
yourself. They do packet things after dinner until they struggle to bed at 3AM. TAPR Is not a commercial entity, but 
rather a fragile confederation of persons who band together because they can do more as a team than they can as individuals. 
They have Jobs and families to take care of, too. Anyone/everyone is welcome to become directly involved in TAPR activities. 
All you have to do is volunteer the necessary time and skills... In a nutshell: TAPR is all of us! 


PUBLICATIONS - TAPR publishes the PSR Quarterly four times a year and sends it to all members. The Board has been discussing 
the idea of merging with the monthly publication, Packet Radio Magazine (PRM) to be in more frequent communication with the 
membership. Merging MAY require us to raise dues. PRM is included as a membership benefit in many regional packet 
organizations already. PSR has never accepted any advertising from anyone at anytime. PRM is supported by advertising 
Please help us decide on this issue! 

1) I Joined TAPR to ] receive PSRQ G) support packet development ( ) both. 

2) I already receive PRM (] yes (] no. 

3) IT PSRQ were to verge with PRM, I would remain a TAPR member (] yes (] no. 


4) I would be willing to pay higher dues of $ to receive PRM with my TAPR membership. 


5) I view the information TAPR publishes in PSRQ as (] important ( ) unimportant. 

6) I would remain a member of TAPR if there were no newsletter at all ) yes ( ) no. 

7) I would remain a member of TAPR if there were no newsletter, but at a reduced dues rate () yes () no. 

8) I plan on renewing my membership in TAPR if things remain as they are ( ) yes () no. 

9) PSRQ should merge with PRM ( ) yes () no. 

10) Advertising in PRM should be an issue in deciding whether to merge (I] yes () no. 
MEMBERSHIP BENEFITS - There has been discussion that TAPR should become a central point for distributing packet software 
developed by non-commercial parties. Programs such as bulletin board software (WORLI, WA7MBL, etc.). terminal programs for 
various computers and the like would probably head the list. What do you think? 

11) TAPR should establish a software exchange for non-commercial packet software () yes (] no. 
There has been some mention of TAPR establishing a presence on a major telephone-accessed database for easy conferencing and 
discussion among members. Such a method may provide a more direct pipeline to your Board and Officers. Of course, such 
services cost money and access would not be free! Please tell us your opinions. 

12) TAPR should institute a packet conference on one of the major databases (] yes (] no. 


If you answered yes to the above, please answer the following three questions. 


13) The database should be () CompuServe (] The Source (I PeopleLink () GENIE ( ) DRNET () other 


14) TAPR members only should be allowed access to this service (] yes () no. 

15) TAPR members should get a discount or credit towards this database conference (] yes (] no. 
TAPR has never released its membership list to any commercial entity. We have been asked for it from time to time, however. 
Also, some members have expressed an interest in getting a list to help find others in their area. Please advise us on this 
issue. 

16) TAPR should publish the membership list on a regular basis () yes () no. 

17) TAPR should sel] the membership list in the form of labels for interested advertisers () yes () no. 
KITS - TAPR has always provided packet equipment in the form of complete kits. The HF tuning indicator is available as a 
partial kit. The NNC is pretty complex, and the high-speed radios may be tricky to assemble and align without proper test 
equipment. on the other hand, licensing the TNC 2 to various manufacturers has resulted in being able to better focus on 
packet development while reaping some benefits from TNC sales in the form of a smal] royalty. Again, we are looking for your 
inputs! 

18) When TAPR makes a kit, it should be a complete kit () yes ( ) no. 

19) Simpler devices and accessories should be available in kit form from TAPR ( ) yes (] no. 


20) Complex devices are better left to the manufacturers to produce (] yes () no. 


21) TAPR should do R and D in packet technology. but stay out of the production business () yes () no. 


22)Having very similar equipemnt produced by many manufacturers is confusing. TAPR should license its technology on 
an exclusive basis only ( yes ( ) no. 


23)Similar equipment from many manufacturers increases competition and TAPR should continue its policy of non-exclusive 
licensing to anyone who meets the terms () yes () no. 


A NEW NAME - Some members have expressed the thought that belonging to a “Tucson” organization seems a little strange. TAPR 
has obvious national roles and some international influence and should change its name to reflect this. 


24) Tucson Amateur Packet Radio is too regional. Change the name { ) yes ( ) no. 
25) If the name changes. the Initials TAPR should remain () yes ( ) no. 


If you think the name should change, what do you suggest? 


ARE WE FINISHED? - There has been some discussion that TAPR has served its purpose, packet is here to stay, and we should 
close the doors. The manufacturers will provide the advanced technology and leadership in the packet arena. What do you 
think? 


26) TAPR Is an organization whose time is past. We should close the doors () yes () no. 


27) TAPR is vital to the continued growth and future of packet radio development and should stay in existence 
] yes 0) no. 


28)I believe that TAPR should be active in petitioning the FCC on actions which directly affect Packet Radio. e.g. the 
automatic digital control docket] () yes () no. 


29) ¥ believe that TAPR should be active in petitioning the FCC on actions which peripherally affect Packet Radio. e.g. the 
Novice Enhancement or Repeater Coordination dockets] () yes ( } no. 


At its February Board meeting, the following three goals were set for TAPR. Please rate the goals using the following code: 
lsatrongly disagree, 2=disagree, 3=no opinion. 4eagree Sestrongly agree 


A] Tucson Amateur Packet Radio will take an active role in participating in the FCC rulemaking process on issues relating 
to Amateur packet radio. Further, TAPR will coordinate such activities with other Amateur organizations. 
Goal #1: 1 2 3 4 5 

B) Tucson Amateur Packet Radio will seek better and faster ways of providing information to the Amateur packet community. 
Goal #2:1 2 3 4 5 

c) Tucson Amateur Packet Radio will encourage and support hardware and software projects to advance the state of the 
art in Amateur packet communications. 
Goal #3: 1 2 3 4 5 


FINAL COMMENTS — Please use the remaining space to offer us any suggestions you may have regarding TAPR, its role in Amateur 
packet radio, how it may better serve your needs, etc. Thank you very much! 
(NOTE: This form is designed to be folded in thirds and mailed without an envelope. Do not forget to apply postage. ] 


Place 
First Class 
Postage here 


Tucson Amateur Packet Radio Corp. 
P.O. Box 22888 


Tucson, AZ 85734 


